![[アップデート] IAM Access Analyzer が新たに 6 つのリソースタイプの分析に対応しました(全12種に!)](https://devio2023-media.developers.io/wp-content/uploads/2022/08/aws-iam.png)
[アップデート] IAM Access Analyzer が新たに 6 つのリソースタイプの分析に対応しました(全12種に!)
コンバンハ、千葉(幸)です。
IAM Access Analyzer による分析対象となるリソースタイプが 6つ追加されました。
これまで IAM Access Analyzer による分析は(主に)リソースベースポリシーを対象にしていましたが、EBSスナップショットなどのリソースベースポリシーを持たないリソースタイプもサポートされるようになりました。
IAM Access Analyzer によるリソースの分析
IAM Access Analyzer によるリソースの分析とは、「対象のリソースが外部エンティティからアクセス可能になっていないかの識別」のことを指します。
「自身の AWS アカウント」もしくは「自身の所属する Organizations 組織」を信頼ゾーンとし、それ以外を外部とみなします。アナライザーというコンポーネントを作成し、信頼ゾーンを定義することで分析が開始されます。
ここでは分析のことを「スキャン」と呼ぶことにすると、スキャンのタイミングは以下の通りです。
- アナライザー作成時のすべての対象リソースに対するスキャン
- 定期スキャン(24時間以内の間隔)
- 手動での再スキャン(検知済みのリソースが対象)
- 検知済みのリソースの変更、もしくは新規リソースの作成をトリガーとするスキャン(30分以内。稀に例外あり)
IAM Access Analyzer 分析対象リソースタイプまとめ
リソースタイプ、対応時期、分析対象をまとめたのが以下表です。
# | リソースタイプ | 対応時期 | 分析対象 |
---|---|---|---|
1 | S3 バケット | 2019年12月 | S3バケットポリシー、ACL、アクセスポイント |
2 | IAM ロール | 2019年12月 | 信頼ポリシー |
3 | KMS キー | 2019年12月 | キーポリシー、Grant |
4 | Lambd 関数・レイヤー | 2019年12月 | リソースベースポリシー |
5 | SQS キュー | 2019年12月 | リソースベースポリシー |
6 | Secrets Manager シークレット | 2021年1月 | リソースベースポリシー |
7 | SNS トピック | 2022年10月 | リソースベースポリシー |
8 | EBS ボリュームスナップショット | 2022年10月 | 共有許可 |
9 | RDS DB スナップショット | 2022年10月 | 共有許可 |
10 | RDS DB クラスタースナップショット | 2022年10月 | 共有許可 |
11 | ECR リポジトリ | 2022年10月 | リソースベースポリシー |
12 | EFS ファイルシステム | 2022年10月 | ファイルシステムポリシー |
これまで IAM Access Analyzer のリリースより後に追加されたリソースタイプは #6 の Secrets Manager シークレットのみでしたが、今回のアップデートにより一気に 6 個増えました。
やってみた
新たにサポート対象となったリソースタイプのうち、EBS スナップショットに対する分析を試してみます。
EBS スナップショットについては気になる記述がありました。(先述のドキュメントより引用)
When customers preview external access of an Amazon EBS snapshot, they can specify the encryption key as an indicator that the snapshot is encrypted, similar to how IAM Access Analyzer preview handles Secrets Manager secrets.
(機械翻訳)
お客様が Amazon EBS スナップショットの外部アクセスをプレビューするとき、IAM Access Analyzer プレビューが Secrets Manager シークレットを処理する方法と同様に、スナップショットが暗号化されていることを示すインジケーターとして暗号化キーを指定できます。
正直これについては何を言っているのかが理解しきれませんでしたが、例えば以下のケースでは検知対象にならないのか?という仮説を立てました。
- EBS スナップショットは共有されている
- EBS スナップショットはカスタマー管理の KMS キーにより暗号化されており、そのキーはクロスアカウントアクセスが許可されていない
以下の構成で 2種類の EBS スナップショットをアカウント間共有し、アナライザーにより検知されるかを試してみます。
- 共有元アカウント:
000000000000
- 共有先アカウント:
999999999999
KMS キーの準備
以下のキーポリシーを持つ KMS キーを作成しました。
{ "Id": "key-consolepolicy-3", "Version": "2012-10-17", "Statement": [ { "Sid": "Enable IAM User Permissions", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::000000000000:root" }, "Action": "kms:*", "Resource": "*" } ] }
ここで許可されているのは000000000000
のアカウントだけです。
EBS スナップショットの準備
以下の手順で2種類の EBS スナップショットを作成しました。
- 暗号化されていない EBS ボリュームを作成
- 1.の EBS ボリュームから暗号化なしの EBS スナップショットを作成(ここで暗号化はできない)
- 2.の EBS スナップショットをコピーし、コピー時に先の手順で準備した KMS キーを指定
EBS スナップショットの共有
EBS スナップショットの画面より、アクセス権限を変更しアカウント間で共有できます。
以下のいずれでも操作可能です。
- 「アクション」→「アクセス権限を変更」
- アクセス許可タブより「アカウント ID を追加」
以下の画面で共有先の AWS アカウントを選択できます。パブリックにすることも可能ですが、その影響はきちんと考慮しましょう。
ちなみにデフォルトキーで暗号化された EBS スナップショットは共有できない
今回の趣旨とは外れますが、デフォルトキー(aws/ebs
)で暗号化された EBS スナップショットは共有の操作ができません。
詳細は以下のあたりをご参照ください。
アナライザーの検知結果を確認する
共有が完了したのち、アナライザーの結果を確認します。放っておいてもスキャンされるはずですが、待ちきれなかったのでアナライザーを削除→再作成することで即時のスキャンを試みました。
なお、アナライザーでは信頼ゾーンとして自身の AWS アカウントを指定しています。
結果としては、暗号化なし・暗号化済みのいずれの EBS スナップショットも検知されていました。
暗号化済みのスナップショットの詳細を確認すると以下のようになっています。
アクセスレベルとしては以下が記録されています。
- Write
- ec2:CopySnapshot
- ec2:CreateVolume
- ec2:DisableFastSnapshotRestores
- ec2:EnableFastSnapshotRestores
- Read
- ec2:DescribeFastSnapshotRestores
- List
- ec2:DescribeSnapshotAttribute
- ec2:DescribeSnapshots
暗号化に用いられている KMS キーはクロスアカウント許可がありませんが、アナライザーの検知対象に含まれています。つまりわたしの仮説は誤っていました。
ひとまず、他のアカウントに共有をしている EBS スナップショットがアナライザーにより検知されたことが確認できました。
ちなみに共有先アカウントでは
共有先のアカウントでは、ふたつの EBS スナップショットが参照できています。
暗号化済み EBS スナップショットからボリュームの作成を試みると、特にエラーは出ず「正常に作成されました」と表示されます。
……が、実際に作成はされていません。共有先 アカウントの CloudTrail からイベントを確認しても「KMS キーへの権限が足りず失敗した」といった内容は確認できないため、なかなか難しい扱いになっています。
また、スナップショットのコピーを試みても数分程度の時間を要したのちにエラーになりました。
KMS キーによって暗号化された EBS スナップショットを共有する際には、そのキーのアクセス許可も考慮してあげる必要があります。
アクセスアナライザーくん最近頑張ってるね
IAM Access Analyzer による分析対象のリソースタイプが増えた、というアップデートでした。
これまでアナライザーによる分析と言えば「リソースベースポリシーを分析してくれるもの」というイメージでいましたが、リソースベースポリシーを持たないリソースタイプも対象に含まれました。
また、2022年10月には他にも IAM Acceess Analyzer 関連のアップデートがあります。最近頑張ってるなという印象を感じます。
どんどん強くなっていく IAM Access Analyser を活用して環境のセキュリティレベルを上げていきましょい。
以上、 チバユキ (@batchicchi) がお送りしました。
参考
2021年1月当時のアップデート内容です。当時からサービスロール用のポリシーAccessAnalyzerServiceRolePolicy
は SNS の権限を持ってたんだなとしみじみしました。